VPNs are services whereby a network provider allows a customer to have some control over how their data is transmitted over a network, e.g. by retaining local control over their addressing scheme or by requesting transport to an associated remote location while letting the network provider devise the best method for transporting the data. Conventional VPNs are assumed to be provided using a fully distributed mechanism wherein each border node presents a customer interface and provides appropriate functions to the customer equipment.
One issue associated with VPNs is the discovery of other members of the same VPN and the restriction of calls or connections to the closed membership of that VPN. A number of mechanisms have been proposed for this, including the provisioning of this information, discovery using an exterior routing protocol, such as Border Gateway Protocol (BGP) or Interior Gateway Protocol (IGP), and discovery using RADIUS. These mechanisms are presented in various standards. The favored mechanism is discovery using BGP.
A basic model for VPN services is illustrated in FIG. 1. Referring to FIG. 1, there are two VPNs, each consisting of Customer Edge (CE) equipment 10,12 belonging to a customer, Provider Edge (PE) equipment 14 belonging to a service provider, and other Provider (P) equipment and infrastructure 16 belonging to the service provider. In the basic model for VPN services, CE equipment 10,12 belonging to a particular VPN, such as the VPN illustrated with “solid” lines or the VPN illustrated with “dashed” lines, exchange data as if a separate, private network connects them together, despite the fact that the two VPNs share the common network 18 of the service provider. If Layer 1 connections are used to connect the CE equipment 10,12, this is considered an L1 VPN; if Layer 2 connections are used to connect the CE equipment 10,12, this is considered an L2 VPN; if Layer 3 connections are used to connect the CE equipment 10,12, this is considered an L3 VPN; etc.
It is expected that the service provider ensures that the data exchanged via one VPN is not shared with the other VPN, i.e. that the two VPNs are isolated from one another. It is also expected that the addressing space used by one VPN is dedicated to that VPN, i.e. that that VPN has control over the allocation of addresses to the corresponding CE equipment 10,12, independent of the addressing space used by the common network 18 of the service provider. One important function of the common network 18 of the service provider is to support the necessary capabilities at the PE equipment 14 to ensure the isolation of the data exchanged and the understanding of the customers' addressing spaces, i.e. if CE1 wants to send data to CE2, the service provider's PE equipment 14 must understand where CE1 and CE2 are in the common network 18 and how to exchange the data between them.
A standard BGP-based model for VPN services, designed to work between peer entities, is illustrated in FIG. 2. Referring to FIG. 2, the BGP routing protocol is used between the PE equipment 14 to exchange information that is required to support the isolation and address mapping that is required for VPN services. This mechanism involves the establishment of BGP sessions between the PE equipment 14 and the exchange of VPN-related information. Specifically, each PE node 14 uses a BGP session associated with a particular VPN to pass a record of the Customer Port Identifier (CPI):Provider Port Identifier (PPI) mapping. BGP filtering is used to ensure that only information associated with the particular VPN is carried on the particular BGP session. As a result, each PE node 14 receives information about the ports used for the particular VPN and how these ports are associated with the CPIs. The customer can use their own CPI to request connection and data exchange between their CE equipment 10,12 within the particular VPN. Any changes in VPN membership or addressing space are reflected in subsequent exchanges of information over BGP sessions, such that the VPN information is kept up-to-date.
Individual BGP sessions are required between the PE equipment 14 belonging to a particular VPN, and multiple BGP sessions are required in order to support multiple VPNs associated with a particular PE node 14. The use of the BGP routing protocol and its associated processing overhead is required specifically for VPN support, and its use is not otherwise necessary.
An IGP advertisement-based model for VPN services is illustrated in FIGS. 3-5. Referring to FIGS. 3-5, a special VPN element is added to the normal routing protocol used in the common network 18 of the service provider (i.e. the IGP). The IGP is used for the routing of data between nodes within the common network 18, either consisting of connections in an L1 network or packet data in an L2 or L3 network. The IGP advertises a separate protocol element to carry data about the VPNs that are locally supported by the advertiser (i.e. the advertising router). This information is “flooded” in the normal process of interior routing to all PE nodes 14 and P nodes 16, and thus is distributed to all PE nodes 14. Again, updates are provided to keep the VPN information up-to-date concerning CE membership and addressing spaces.
The basic VPN advertisement includes a VPN identifier and a PE identifier, linking particular PE nodes 14 with a particular VPN. Presumably, information concerning the CE identifiers supported by a particular PE node 14 is added so that specific routing based on the CE identifiers can be supported.
The basic operation of the IGP advertisement-based model for VPN services is illustrated in FIGS. 3-5. Each PE node 14 generates VPN advertisements and “floods” these VPN advertisements to other P nodes 16 using the IGP procedures. Each PE node 14 then builds its membership and addressing tables using the received information. The VPN advertisements are a relatively new IGP requirement and are not supported by existing IGP routing protocols. Disadvantageously, they add additional advertisements to be carried by the routing protocols.
Disadvantageously, the models for VPN services described above require the implementation of another, complex routing protocol, BGP or IGP, which involves the establishment of individual Transmission Control Protocol (TCP) sessions between the endpoint nodes participating in the VPN. The impact of this is complexity—BGP and IGP are distinct routing protocols which each require a distinct routing protocol stack and trained maintenance staff; cost—again BGP and IGP are distinct routing protocols which each require a distinct routing protocol stack and additional development and testing resources; additional processing overhead—the distinct routing protocol stacks for BGP and IGP each have their own routing adjacency and keep-alive, and multiple TCP sessions are required, adding considerable overhead to the Central Processing Unit (CPU) processing load; and deployment difficulties—it can be difficult to deploy a VPN across a large network of switches due to the need to update the software of each switch with BGP or IGP, administer the establishment of TCP sessions, etc.